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[57] ABSTRACT 

A configuration-independent software architecture for 
implementing a cellular communication network that facili- 
tates communication among a plurality of cellular handsets. 
The architecture includes a first software functional block 
for implementing a first set of functions and a second 
software functional block for implementing a second set of 
functions. The architecture further includes a configuration- 
independent linkage block, which has an interface that 
appears consistent to both the first software functional block 
and the second software functional block irrespective of a 
relative position between the second software functional 
block, the first software functional block, and the 
configuration-independent linkage block in the cellular com- 
munication network. The configuration-independent linkage 
block facilitates communication between the first software 
functional block and the second software functional block 
via the interface utilizing configuration-independent linkage 
block. Advantageously, the first software functional block, 
the second software functional block, and the interface 
remain substantially unchanged when the first software 
functional block changes its location in the cellular com- 
munication network relative to the second software func- 
tional block. 

23 Claims, 11 Drawing Sheets 
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CONFIGURATION-INDEPENDENT 
METHODS AND APPARATUS FOR 
SOFTWARE COMMUNICATION IN A 
CELLULAR NETWORK 

BACKGROUND OF THE INVENTION 

This is a continuation-in-part of commonly assigned U.S. 
patent Ser. No. 08/435,709, entitled "Cellular Private Branch 
Exchange," (Attorney's Docket No. WAVEP001), filed May 
4, 1995 U.S. Pat. No. 5,734,699 (hereinafter Ser. No. 10 
08/435,709). 

The following U.S. patent applications are incorporated 
herein by reference for all purposes: 

"Cellular Private Branch Exchange," (Attorney's Docket 
No. WAVEP001) filed May 4, 1995 and issued as U.S. Pat. 
No. 5,734,699 (hereinafter Ser. No. 08/435,709). 

"Cellular Communication Network Having Intelligent 
Switching Nodes," (title as amended) filed May 4, 1995, 
U.S. Ser. No. 08/435,838, and issued as U.S. Pat. No. 20 
5,577,029 Attorney's Docket No. WAVEP004 (hereinafter 
"Ser. No. 08/435,838"). 

"Hybrid Cellular Communication Apparatus And 
Method," filed on even date, U.S. Ser. No. (08/729,546), 
Attorney's Docket No. WAVEP003 (hereinafter 2 5 
"WAVEP003") and the earlier filed provisional application 
entitled "Hybrid Cellular Communication Apparatus And 
Method" filed Nov. 10, 1995 application Ser. No. 60/006, 
589 by inventors Priscilla Marilyn Lu and Timothy Richard 
White from which that application claims priority under 35 30 
U.S.C. 119(e). 

"Spread Spectrum Communication Network Signal 
Processor," filed on May 4, 1995, Ser. No. 08/434,554, and 
issued as U.S. Pat. No. 5,682,403 Attorney's Docket No: 
A-60910 (hereinafter Ser. No. 08/434,554). 35 

"Cellular Base Station With Intelligent Call Routing," 
filed on May 4, 1995, Ser. No. 08/434,598, and issued as 
U.S. Pat. No. 5,734,979 Attorney's Docket No: A-61115 
(hereinafter Ser. No. 08/434,598). 

"Spectrum Communication Network With Adaptive Fre- 40 
quency Agility," filed on May 4, 1995, Ser. No. 08/434,597, 
Attorney's Docket No: A-60820 (hereinafter Ser. No. 
08/434,597). 

For ease of reference, a glossary of terms and abbrevia- 
tions is provided herewith as Appendix A. 

BACKGROUND OF THE INVENTION 

The present invention relates to networks for cellular 
communication service. More specifically, the invention 5Q 
relates to methods and apparatus for implementing software 
in a cellular network. 

FIG. 1 is a diagram illustrating the components of a 
representative cellular network, including a Mobile Switch- 
ing Center (MSC) 100, a Base Station Controller (BSC) 102, 55 
a Base Transceiver Station (BTS) 104, and a plurality of 
cellular handsets 106(d)-106(fc). The components of the 
representative cellular network of FIG. 1 has been discussed 
extensively in the aforementioned patent applications. 

In the prior art, each component of the cellular network, eo 
i.e., MSC 100, BSC 102, and BTS 104, is implemented on 
a discrete chassis and housed in a discrete "box." The boxes 
themselves are then dispersed as required in a geographic 
location, coupled together by trunk lines to complete the 
cellular network. 65 

Present implementation of each of MSC 100, BSC 102, 
and BTS 104 typically includes two main parts: hardware 
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and software. Hardware generally includes the relatively 
fixed physical circuitries while software, being 
programmable, is generally easier than hardware to design, 
implement, and modify. Consequently, while a certain 
amount of hardware is necessary, it is generally considered 
desirable to implement as much of the functionalities of the 
cellular network in software as possible. This is particularly 
true in view of the availability of modern high speed 
processors and programmable circuitries. 

On one level, it is possible to discuss the implementation 
and operation of the components of a representative cellular 
network in terms of its software. By way of example, FIG. 
2 is a diagram illustrating a prior art implementation of the 
software functional blocks for implementing components of 
the prior art cellular network. Referring now to FIG. 2, there 
are shown three boxes: 200, 202, and 204, which contain the 
hardware necessary for implementing respectively the MSC, 
the BSC, and the BTS components. As shown in FIG. 2, 
there is also provided in box 200 the software for imple- 
menting the MSC function, the A interface necessary for 
communicating with the software implementing the BSC in 
box 202, and El resources to communicate therewith across 
trunk line 206. In addition to the requisite hardware, box 202 
contains the software for implementing the BSC function, 
the A interface to communicate with the software imple- 
menting the MSC in unit 200, and El resources for com- 
municating therewith across trunk line 206. To communicate 
with software implementing the BTS in box 204, there is 
further provided in box 202 software for implementing the 
Abis interface and El resources for communicating across a 
trunk line 208. 

In a similar manner, box 204 contains the software for 
implementing the BTS function, the Abis interface for 
communicating with the software implementing the BSC in 
unit 202, and El resources to facilitate the communication 
therewith. To communicate with its handsets (not shown), 
box 204 further includes the software for implementing the 
LAPDm facility 212, which in cooperation with software 
implementing TRX resources 214, permits the software 
implementing the BTS function in block 204 to communi- 
cate with its cellular handsets. 

In the prior art each of the software implementing boxes 
200, 202, and 204 is customized for a particular cellular 
network configuration. As the term is used herein, cellular 
network configuration refers to the MSC's, BSC's, and 
BTS's in a cellular network, as well as the particular manner 
in which they are combined, either in one chassis or across 
multiple chassis. When cellular network configuration 
changes in the prior art, for example by adding or removing 
BSC's or BTS's to satisfy domain and capacity 
requirements, the affected software must be recoded to 
account for the changes. 

By way of example, when a BTS is added to the domain 
of a BSC and needs to communicate with that BSC, the prior 
art software implementing the BSC must typically be 
recoded to account for this change. As another example, if 
it is decided to collapse the BSC and BTS functions of FIG. 
2 into one chassis, say to provide a smaller package to 
reduce hardware costs and to simplify maintenance and/or 
upgrade, it is necessary in the prior art to recode both the 
software implementing the BSC and the software imple- 
menting the BTS to account for the fact that these two 
components no longer need to employ trunk resources for 
communicating with each other (since they now reside 
within the same chassis). 

Alternatively, if a cellular network is initially configured 
as a single chassis in which the MSC, the BSC, and the BTS 



07/02/2004, EAST Version: 1.4.1 



3 

co-reside (as was disclosed in one embodiment of 
co-pending patent application Ser. No. 08/435,709, and 
additional remote BTS's are added to the network to expand 
cellular network capacity at a later date, the prior art method 
of implementing its software typically requires substantial 
recoding of the software of the affected components, which 
may include the MSC, the BSC and the BTS. 

Further, the prior art paradigm of implementing the soft- 
ware of the MSC, the BSC, and the BTS of the cellular 
network requires extensive knowledge regarding how data 
must be routed in a particular network configuration on the 
part of the application developer, i.e., those who develop the 
software that implements the software functional blocks 
such as the MSC, the BSC, or the BTS. The fact that the 
software functional blocks of the prior art must be changed 
to accommodate modifications to the network configuration 
means that relatively substantial expenditures, both in term 
of time and expenses, are required when the cellular network 
is upgraded, or scaled up or down responsive to changes in 
domain and capacity requirements. 

In view of the above, what is desired is an improved 
method and apparatus for implementing the software of a 
cellular network in a manner that is as independent of 
cellular network configuration as possible. It is also desired 
that the improved method and apparatus implements the 
MSC, the BSC, and the BTS as substantially unchanging 
blocks of code irrespective of cellular network configura- 
tion. More importantly, it is desired that these substantially 
unchanging blocks of code, which implement the MSC, the 
BSC, and the BTS of the cellular network, communicate 
among themselves using an interface that is also substan- 
tially unchanged irrespective of changes in the configuration 
of the cellular network. 

SUMMARY OF THE INVENTION 

The present invention relates in one embodiment, to a 
configuration-independent software architecture for imple- 
menting a cellular communication network that facilitates 
communication among a plurality of cellular handsets. 

The architecture includes a first software functional block 
for implementing a first set of functions and a second 
software functional block for implementing a second set of 
functions. The architecture further includes a configuration- 
independent linkage block, which has an interface that 
appears consistent to both the first software functional block 
and the second software functional block irrespective of a 
relative position between the second software functional 
block, the first software functional block, and the 
configuration-independent linkage block in the cellular com- 
munication network. 

The configuration-independent linkage block facilitates 
communication between the first software functional block 
and the second software functional block via the interface 
utilizing configuration-independent linkage block. 
Advantageously, the first software functional block, the 
second software functional block, and the interface remain 
substantially unchanged when the first software functional 
block changes its location in the cellular communication 
network relative to the second software functional block. 

In one specific embodiment, the first software functional 
block is a base transceiver station software functional block 
and the first set of functions is a set of base transceiver 
station functions, while the second software functional block 
is a base station controller software functional block and the 
second set of functions is a set of base station controller 
functions. 
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In yet another embodiment, the invention relates to a 
method for facilitating communication among a plurality of 
software functional blocks in a cellular communication 
network which has a plurality of central processing units. 

5 The method includes the step of providing a first software 
functional block for implementing a first set of functions. 
The first software functional block is executed on a first 
central processing unit in the cellular communication net- 
work. The method further includes the step of providing a 

J0 second software functional block for implementing a second 
set of functions. The second software functional block 
represents a first instantiation of a block of codes represent- 
ing the second set of functions. 

The inventive method further includes the step of provid- 
ing a third software functional block for implementing the 

35 second set of functions. This third software functional block 
represents a second instantiation of the block of codes 
representing the second set of functions. Furthermore, the 
inventive method includes the step of facilitating 
configuration-independent communication between the first 

20 software functional block and both the second and third 
software functional blocks using at least one configuration- 
independent linkage block. In accordance with one aspect of 
the invention, the configuration-independent linkage block 
has internal ftmctions that transparently implements, from 

25 the perspectives of the first, second, and third software 
functional blocks, configuration-specific communication 
among the first, second, and third software functional 
blocks. The configuration-independent communication 
takes place via an interface that is substantially consistent 

30 irrespective whether the second and third software func- 
tional blocks execute on the first central processing unit or 
on different central processing units in the cellular commu- 
nication network. Irrespective of this, the first, second, and 
third software functional blocks remain substantially 

35 unchanged across network configurations. 

In yet another embodiment, the first, second, and third 
software functional blocks and the interface remain substan- 
tially unchanged irrespective whether the second and third 
software functional blocks are executed on a second central 

40 processing unit that is different from the first central pro- 
cessing unit or on two different central processing units that 
are different from the first central processing unit. 

BRIEF DESCRIPTION OF DRAWINGS 

45 Additional advantages of the invention will become 
apparent upon reading the following detailed description and 
upon reference to the drawings, in which: 

FIG. 1 is a diagram illustrating the components of a 
representative cellular network; 

50 FIG. 2 is a diagram illustrating a prior art implementation 
of the software functional blocks for implementing compo- 
nents of the prior art cellular network; 

FIG. 3 illustrates, in one aspect of the present invention, 
the configuration-independent architecture of the software 

55 functional blocks (SFB's), which implement the compo- 
nents of the cellular network; 

FIG. 4A illustrates an example of a cellular network 
configuration wherein the base station controller (BSC) and 
the mobile station controller (MSC) SFB's co-reside on a 

60 single central processing unit (CPU) in a single chassis 
while the base transceiver station (BTS) software functional 
block is remoted in a different CPU on a different chassis; 

FIG. 4B illustrates an example of a cellular network 
configuration in which the BSC software functional block 

65 and the BTS software functional block co-reside on a single 
chassis while the MSC SFB is remoted on a different 
chassis; 
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FIG. 5 illustrates a BSS implementation in which a BSC 
software functional block and a BTS software functional 
block co-reside in the same CPU/chassis; 

FIG. 6Ais a diagram illustrating, in one embodiment, the 
relationship between the communication protocols between 5 
two SFB's such as a BSC SFB and a BTS SFB as well as the 
actual data exchange that takes place within a configuration- 
independent linkage block (CILB) between them; 

In FIG. 6B, the BSC SFB and the BTS SFB are distributed 
in different CPU's/chassis. 30 

FIG. 7 is a diagram illustrating, in one embodiment, a 
message passing paradigm for facilitating communication 
between SFB's in a configuration-independent manner; 

FIG. 8 illustrates how multiple SFB's may utilize sub- 35 
routines in a library of subroutines to communicate in a 
configuration independent manner; 

FIG. 9A shows, in one embodiment, a multiple-layer 
communication stack for communicating among SFB's; 

FIG. 9B shows the communication, using the inventive 2 o 
configuration independent architecture technique, between a 
BSC SFB and an MSC SFB; 

FIG. 10 illustrates the message passing paradigm for 
communicating among different SFB's; 

FIG. 11 shows an example of a routing table associated 25 
with a CPU; 

FIG. 12 illustrates the communication between a BSC 
administration SFB and an A-intcrface SFB when these two 
SFB's are remoted from one another; and 

FIG. 13 illustrates the communication between a single 30 
BSC administration SFB and three BTS manager SFB's, 
which are implemented on three discrete cellular central 
processing unit (CCPU) cards. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

FIG. 3 illustrates, in one aspect of the present invention, 
the configuration- independent architecture of the software 
functional blocks (SFB's), which implement the compo- 
nents of the cellular network. In FIG. 3, the three SFB's 40 
MSC 220, BSC 222, and BTS 224 are coupled together via 
configuration-independent linkage blocks (CILB) 226 and 
228, In accordance with one aspect of the invention and as 
will be discussed in detail later, CILB 226 includes an 
interface that appears substantially unchanged to both MSC 45 
SFB 220 and BSC SFB 222 irrespective of the configuration 
of the cellular network. In other words, the manner in which 
MSC SFB 220 and BSC SFB 222 communicate with CILB 
226 remains substantially unchanged irrespective of whether 
these two SFB's are executed in the same central processing 50 
unit (CPU), implemented in the same physical chassis (i.e., 
on the same chassis) but executed on different CPU's, or 
remoted in geographically dispersed chassis that are linked 
together via trunk lines. 

To clarify, when two SFB's are referred to herein as being 55 
implemented on the same CPU/chassis, these two SFB's 
may be executing on the same CPU in that chassis or in 
multiple CPU's in that same chassis. When multiple CPU's 
are provided in a single chassis, greater processing power 
can be provided on that chassis. Multiple CPU's may be 60 
tightly coupled, i.e., sharing memory resources and other 
resources, or loosely coupled, i.e., utilizing the same bus 
although each CPU is provided with its own memory and 
other resources. In contrast, when two SFB's are remoted 
from one another, they are executed on different CPU's in 65 
different chassis, and communication between these SFB's 
requires remote communication resources, e.g., El. 
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Further, it is preferable that the interface between CILB 
228 and BSC SFB 222 (as well as between CILB 228 and 
BTS SFB 224) remains substantially unchanged irrespective 
of cellular network configuration. 

In accordance with another aspect of the invention, the 
software codes that implement these major SFB's, e.g., 
MSC SFB 220, BSC SFB 222, BTS SFB 224, and radio- 
dependent SFB's (e.g., TRX SFB 230) stay substantially 
unchanged irrespective of cellular network configuration. In 
this manner, each block of codes for implementing the 
cellular network components may be made modular, thereby 
simplifying network expansion, upgrade, and maintenance. 

In one aspect of the present invention, the major SFB's for 
implementing the cellular network components may flexibly 
be combined, either in a single CPU/chassis or be remoted 
among combinations of CPU/chassis, thereby making it 
possible to offer custom solutions to fit particular geographic 
or capacity requirements in a low-cost manner. Because the 
major SFB's can be recombined among different CPU's/ 
chassis in a manner so as not to require substantial recoding 
of the major SFB's, this aspect of the present invention 
advantageously simplifies network upgrade and scaling, i.e., 
expanding and contracting by respectively adding or remov- 
ing network components to suit the changing domain or 
capacity requirements of a cellular network. 

In a new market, the inventive configuration-independent 
architecture allows a cellular provider to offer a cellular 
network that is less expensive and possesses higher perfor- 
mance characteristics than possible in the prior art by using 
a single chassis to implement all four major components 
(i.e., MSC, BSC, BTS, and TRX). By way of example, the 
use of a single chassis to implement all these four major 
components advantageously eliminates the costs, in terms of 
hardware and software, associated with implementing trunk 
resources. When capacity and domain requirements 
increase, e.g., to handle more cellular handsets or to expand 
the area of coverage, the inventive configuration- 
independent architecture permits scaling of the network 
software in a modular and configuration-independent man- 
ner. Since the major SFB's remain substantially unchanged, 
and the manner in which they communicate with one 
another is not dependent on system configuration, network 
upgrade and expansion are substantially simplified. 

In accordance with this aspect of the invention, changes 
in cellular network configuration impact primarily only the 
software functions that underlie the CILB's. By way of 
example, when a cellular network configuration changes 
from a BTS/BSC configuration (both the BTS and the BSC 
co-reside on the same CPU/chassis and the MSC is remoted) 
to a BTS/BSC/MSC configuration (all three SFB's co-reside 
on the same CPU/chassis), it is the software functions 
implementing the CILB's between the SFB's, not the SFB's 
themselves, that change. However, the CILB interfaces 
through which these major SFB's communicate preferably 
stays substantially unchanged from the perspectives of the 
SFB's that implement the MSC, the BSC, and the BTS. 

BTS SFB 224 also communicates with TRX SFB 230 via 
TRX configuration- independent linkage block (CILB) 232, 
which possesses an interface that appears substantially 
unchanged to both BTS SFB 224 and TRX SFB 230 
irrespective of cellular network configuration, i.e., regard- 
less whether they co-reside in the same CPU/chassis or are 
remoted among different CPU's/chassis. As is apparent in 
the above example, the term software functional block is not 
restricted only to blocks of codes that implement the MSC, 
the BSC, and the BTS. In fact, they apply to any executable 
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block of codes that performs a particular task in the cellular related A interface in a remote manner in FIG. 4B and in a 

network and which is substantially immune to changes in local manner in FIG. 4A is also largely hidden from both 

network configuration. BSC SFB 222 and MSC SFB 220 by the configuration- 

F1G. 4A illustrates an example of a cellular network independent interface of CILB 226. 

configuration wherein the BSC and the MSC SFB's 5 By simply modifying the software codes within CILB 226 

co-reside on a single CPU in a single chassis while the BTS and 228j as weU M CILB 232 (not shown in FIGS. 4A and 

^A^^^^^ ^^^^^t^ 4B >> a ccllular network created in accordance with the 

FIG. 4A, MSC SFB 220 communicates with BSC SFB 222 • a a ♦ u » ^ a 

via CILB 226 while BSC SFB 222 communicates with BTS configuration-mdependen architecture may flex- 

SFB 224 via CILB 228. In the specific example of FIG. 4A, M lbl J be reconfigured m a modular and configuration- 

the GSM standard is chosen for illustration purposes " «> de P end ° nt * <*«■> net ™* ;«>nfigura- 

. . , , , * , j «u 4 >l. . • tions without requiring substantial changes to the codes of 

although it should be understood that the present inventive oirD , i f f ... . * 4 . , . 

a • j * ... . » i* "* j ♦ its major SFB s. In fact, it is not necessary for the developers 

configuration-independent architecture is not limited to any J C17D , ' CP n „^ v 0 . rc 

4 . ■ .in r i •» • . i.j of the SFB s, e.g., the MSC, the BSC, the BTS, or the TRX 

particular protocol. By way of example, it is contemplated or .„, . . to V. , . ' ' . ' . . 

f. „ . cJ ^ • / j » u » * SFB s, to know the details regarding data routing in a 

that the inventive configuration-independent architecture .J „ , ^ %. ^, . * 

. . . « • . . v , . 15 specific network configuration. Since the CILB interfaces 

may be implemented using a local area network protocol, r . A 4 . „ * . f . . r . 

such as TCP/IP or other cellular standards such as AMPS remam substantiall y unchanged from the perspective of the 

(Advanced Mobile Phone Services), TACS, and the like. ? *■ ' hese f SFB s ^ b ° developedmdependent of any 

~- ~™ M * , , . , . , knowledge of network configuration. This inventive aspect 

Sm ^ D ? ■ ? , ?' re , "J the P««n» * advantage when the cellular network needs 

same CPU, CILB 226 .s implemented as a local interface, 20 , 0 be ded maintained , scaled (up or down) to satisfy 

and more particular^, a local interface implementing the , he ci aQd domain uirements of a ticular 

GSM -related A interface that utilizes message passing for p ra phic location 

communication. The A interface implemented in the net- „ M1 ' nr>n . , . , 

work of FIG. 4A follows, in one embodiment, the Signaling J} G ' * lU ^ le c S * BSS ^mentation in which a BSC 

Connection Control Part-Message Transfer Part 1-3 (SCCP 25 |™ SFB C0_reSlde ™ SL"™ ^ /< ?* SWS / 

MTP1-3) as described in the GSM specification 08.06. *f" F ^ 

Message passing will be explained later in connection with CILB 304 BSC SFB 300 also communicates with a CILB 

FIG. 7. Further, since BTS SFB 224 is remoted from either 30 * which handles communication between BSC SFB 300 

BSC SFB 222 or MSC SFB 220, CILB 228 is implemented and an MSC ( DOt shown )- 

as a remote interface. In the specific example of FIG. 4A, 30 Wltmn BSC SFB 300 > lhere are shown, for illustration 
CILB 228 is implemented as a remote interface utilizing the purposes, some of the functional blocks for implementing 
GSM-related Abis interface, which utilizes El trunk facili- the B $ c S¥B B Y wa Y of example, functional blocks BSC 
ties and trunk lines to facilitate remote communication. administration 320, BTS manager 322, channel manager 
Most importantly, MSC SFB 220, BSC SFB 222, and 324 > and handover manager 326 are shown. Similarly, there 
BTS SFB 224 stay substantially unchanged irrespective 35 arc shown m BJS SFB 302 BTS administration 328, dedi- 
whether they all co-reside in the same CPU/chassis or are cated channel block 330, and common channel block 332. 
remoted in different CPU's/chassis. Furthermore, the inter- ^ach of functional blocks 320-332 may be thought of as a 
faces of CILB 226 and CILB 228, as well as all CILB's SFB ' i C " lhe y can be remoted or lamented in the same 
implemented in accordance with the technique disclosed CPU/chassis without requiring substantial changes to their 
herein, appears substantially unchanged to the SFB's with 40 internal °° dcs usm S the mventlve CILB concept, 
which they communicate. For example, CILB 226 has an For illustration purposes, there are shown two radio- 
interface that appears substantially unchanged to MSC SFB dependent SFB's 312 and 314 for facilitating communica- 
220 and BSC SFB 222 regardless whether CILB 226 is tion between BTS SFB 302 and the cellular handsets 
implemented as a local interface (as in the example of FIG. (omitted from FIG. 5 for ease of illustration). It should be 
4(a)) or as one that facilitates remote communication 45 understood that a greater or fewer number of radio- 
between SFB's that are remoted in diUerent CPU's/chassis dependent software function blocks (SFB's) may be pro- 
(as in the case where BSC SFB 222 is remoted from MSC vided as necessary to accommodate the number of cellular 
SFB 220 in different CPU's/chassis). Likewise, CILB 228 handsels in a cellular network. 

has an interface that appears substantially unchanged to BSC The radio-dependent SFB performs TRX-dependent func- 

SFB 222 and BTS SFB 224 regardless whether CILB 228 is 50 tions such as communications, LAPDm functions, and TRX 

internally implemented as a local interface or as one that administration functions, and the like. For performing the 

facilitates remote communication. above-mentioned functions, each radio-dependent SFB may 

For comparison purpose, FIG. 4B shows a cellular net- include a LAPDm SFB, a TRX administration SFB, and a 

work configuration in which BSC SFB 222 and BTS SFB digital signal processing (DSP) management SFB. BTS SFB 

224 co-reside on a single chassis while MSC SFB 220 is 55 302 communicates with a CILB 310, which handles com- 

remoted on a different chassis. As in the cases of FIGS. 3 and munication between BTS SFB 302 and a plurality of cellular 

4A, the SFB's communicate using their respective CILB's handsets. Like CILB 232 of FIG. 3, CILB 310 of FIG. 5 

which have consistent interfaces irrespective whether they appears substantially unchanged to BTS SFB 302 irrespec- 

co-reside on the same chassis or are remoted from one tive of the number of radio-dependent SFB's in the cellular 

another. Further, there are substantially no differences 60 network. 

between the BTS, BSC, and MSC SFB's of FIG. 3, and Configuration-independent communication may be 

respective SFB's of FIG. 4A and FIG. 4B. The fact that the accomplished in any manner. For illustration purposes, two 

CILB 228 implements the GSM-related Abis interface in a main communication paradigms for implementing CILB's 

local manner in FIG. 4B and in a remote manner in FIG. 4A are discussed herein. Firstly, configuration -independent 

is largely hidden from BSC SFB 222 and BTS SFB 224 by 65 communication to and from a SFB through a CILB may take 

the configuration-independent interface of CILB 228. place via message passing. In message passing, the sending 

Likewise, the fact that CILB 226 implements the GSM- SFB sends a message to a mailbox having a well-known 
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address. If that destination mailbox is local to the sending 
SFB, i.e., implemented on the same CPU/chassis, the CILB 
merely forwards the message to that destination mailbox to 
be retrieved by the one of the SFB's which monitors the 
mailbox. If the destination mailbox and its associated receiv- 
ing SFB is remoted, i.e., implemented on a different CPU/ 
chassis, the CILB will route the message appropriately. 
From the perspective of the sending SFB, the fact that the 
destination mailbox is implemented locally in one case and 
remoted in another case is substantially hidden. The actual 
details regarding data routing is left to the functions within 
the CILB. 

Alternatively, a CILB may facilitate communication to 
and from a SFB by calling on interface functions, which are 
basically library subroutines that can be linked, either stati- 
cally or dynamically, by the SFB that requires it for com- 
munication. By employing the appropriate functions, the 
CILB can either route data locally or to remote CPU/chassis 
while keeping such configuration-specific details from both 
the sending and the receiving SFB's. 

An example of a CILB that utilizes interface functions to 
permit two SFB's of the cellular network to communicate in 
a configuration-independent manner may be seen in the 
communication between BTS SFB 302 of FIG. 5 and its 
radio-dependent SFB's. When BTS SFB 302 wishes to 
communicate with any of its radio-dependent SFB's, it 
sends data to CILB 310 which happens to be implemented 
partially by a first-in-first-out stack (FIFO). Although not a 
requirement, the FIFO of CILB 310 is implemented, in one 
embodiment, on the same CPU that executes its associated 
radio-dependent SFB. 

To send data to the FIFO of CILB 310, BTS SFB 302 may 
call, for example, a subroutine FifoSend, which is a sub- 
routine whose implementation details are hidden from BTS 
SFB 302. FifoSend is a modular subroutine that handles the 
routing of data between BTS SFB 302 and the FIFO in CILB 
310 in a specific network configuration. Since the imple- 
mentation details regarding data routing is hidden in the 
subroutine FifoSend, BTS SFB 302 may be configured as 
local or remote with respect to the radio-dependent SFB's 
with which it wishes to communicate simply by modifying 
the codes inside the subroutine FifoSend. The SFB's them- 
selves and the manner with which they interact with CILB 
310 remain substantially unchanged from network configu- 
ration to network configuration. This is substantially simpler 
than modifying the much larger SFB's which implement, for 
example, the BTS and the radio-dependent blocks whenever 
network configuration changes, as was required in the prior 
art 

Although a FIFO is shown herein for ease of illustration, 
it should be kept in mind that there exists other methods for 
inlerprocessor communication. Examples of these methods 
include using shared memory, mailboxes, bus protocols 
(serial, parallel, and other known protocols), and the like. 

An example of a CILB which facilitates communication 
to and from a SFB by message passing may be illustrated 
with reference to CILB 304. When BTS SFB 302 wishes to 
communicate with BSC SFB 300, it send messages to a 
well-known mailbox associated with the Abis interface 
implemented by codes within CILB 304. If the message 
passing is done locally, as is the case when both BTS. SFB 
302 and BSC SFB 300 occupy the same CPU/chassis, 
functions in CILB 304 are coded to implement local mes- 
sage passing. On the other hand, when BTS SFB 302 is 
remoted from BSC SFB 300, functions within CILB 304, 
whose details are hidden from both BTS SFB 302 and BSC 
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SFB 300, utilize facilities such as LAPD to ensure that 
messages to and from the intended mailbox can be remotely 
sent or received. Note that from the perspectives of BTS 
SFB 302 and BSC SFB 300, their interaction with CILB 304 

5 remains substantially unchanged irrespective whether these 
two SFB's are configured as remote or local in a given 
network. Further, the interface between CILB 304 and the 
sending as well as the receiving SFB's, e.g., BTS SFB 302 
or BSC SFB 300, remains substantially unchanged irrespec- 
tive of the number of BTS SFB's 302 that are coupled to 

30 BSC SFB 300. 

In the specific example of FIG. 5, the MSC (not shown) 
is implemented on a remote CPU/chassis from that imple- 
menting the BTS/BSC SFB's. Consequently, CILB 306 
must facilitate remote communication. This remote commu- 

35 nication is implemented in FIG. 5 by a remote communi- 
cation SFB. In the specific example of FIG. 5, this remote 
communication SFB is implemented using network inter- 
face controller (NIC) 321, which includes the A interface 
(SCCP MTP1-3 as described by GSM standard 08.06) and 

20 by the El SFB within NIC 321. It should be borne in mind 
that NIC 321 may also implement the Abis protocol to 
function as the CILB associated with each of BSC SFB 300 
amd BTS SFB 302 when the BTS SFB is remoted from the 
BSC SFB (via some physical trunk line). 

If the MSC had been implemented on the same CPU/ 
chassis that implements the BTS/BSC SFB's of FIG. 5, NIC 
321 would not have been necessary and would have been 
replaced by other functions that facilitate local message 
passing between BSC SFB 300 and its associated MSC SFB. 
Note that the interface between CILB 306 and either BSC 
SFB 300 or its associated MSC SFB remains substantially 
unchanged regardless whether their respective communica- 
tion via CILB 306 is local or remote. 

35 It should be kept in mind that the codes that implement 
BSC SFB 300, BTS SFB 302, and radio-dependent SFB's 
312/314 preferably remain substantially unchanged regard- 
less of network configuration. When network configuration 
changes, it is the functions beneath the CILB's that are 

40 modified/replaced to properly route data given the changed 
network configuration. 

Further, the codes which implement the functions under- 
lying the CILB, e.g., those that support the A interface, the 
Abis interface, or implement the real-time processor (RTP), 

45 may either co-reside on the same CPU/chassis with their 
respective BSC/BTS SFB's or may be remoted to their own 
CPU/chassis as necessary to fit processing, geographic 
location, or domain requirements of a cellular network. 
FIG. 6 A is a diagram illustrating the relationship between 

50 the communication protocols between two SFB's such as 
BSC SFB 350 and BTS SFB 352, and the actual data 
exchange that takes place within a CILB between them. 
Note that although BTS and BSC SFB's are used in the 
example, the inventive CILB applies to facilitate commu- 

55 nication between any two SFB's regardless of their relative 
locations in the network. 

In FIG. 6A, BSC SFB 350 communicates with BTS SFB 
352 using the Abis protocol, which is shown diagramatically 
in FIG. 6A as dotted fine 354. Since BTS SFB 352 and BSC 

60 SFB 350 co-reside in the same CPU/chassis in the example 
of FIG. 6 A, data communication between these two SFB's 
is achieved by local software functional block (SFB) com- 
munication (herein "LSC") using primitives implemented 
by the CILB beneath interface line 356. This communication 

65 is shown representatively in FIG. 6A by line 370. 

As the term is used herein, local SFB communication 
(LSC) refers to the communication between SFB's in the 
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same CPU/chassis. Basic functionalities of a LSC consist of, communication paradigm for local communication in the 

among others, passing a unit of information known as a configuration of FIG. 6 A. Note that the primitives 360A and 

message between two SFB's. Note that this is the case 36OB above interface line 356 remain substantially 

irrespective whether the SFB's reside in the same task, as uncha nged in both FIGS. 6A and 6B. Onlv the primitives 

separate tasks within the same CPU, as tasks within separate 5 bdow imefface Une 356 cfa rcs onsiv ' c t0 changes m 

CPU s across a bus, or as tasks on separate CPU's connected . ~ . 0 r , . »•?.!.• 

t , . i t 00 . 1 j « r network configuration to ensure proper data routing. In this 

in a local area network. LSC may take advantage of message . , , 1 „ . 

passing facilities of the underlying operating system (OS) manner > the details regarding the actual data routing is 

that operates the CPU on which the LSC executes. Examples hiddcn from tne receiving and sending SFB's. Such data 

of such OS's are Unix, VxWorks, and VTRX. 1Q hiding makes the SFB's modular, thereby simplifying the 

Some SFB's may require connection -oriented services. j° D °f developers of these major SFB's. 

Connection-oriented services, also known in certain context FIG. 7 is a diagram illustrating, in one embodiment, a 

as virtual circuit services, allow communicating SFB's to message passing paradigm for facilitating communication 

establish a session during which messages associated with between SFB's in a configuration-independent manner, 

that session may be passed among the communicating 15 Referring now to FIG. 7, there are shown three SFB's 400, 

SFB's. To enable this feature, LSC supports, among others, 402, and 404. Each of SFB's 400, 402, and 404 may be 

the establishment and termination of sessions as well as the instantiated from a single task that is intended for accom- 

association of messages with a session. One implementation plishing a certain function, e.g., a block of codes for imple - 

of the primitives for implementing the A interface between menting a BTS. For example, when there are multiple BTS's 

the LSC's and its respective SFB's are shown, for illustra- 20 in a network, multiple instantiations of the BTS task are 

tion purposes, in Appendix C It will be apparent to those necessary to implement the software in all the BTS's. 

skilled in the art that these primitives, which are known in Although not particularly relevant to the discussion regard- 

the industry, vary according to the specific interface imple- ing FIG. 7, it should be noted that software functional blocks 

mented (e.g., A, ISDN, or the like). 25 of codes 400, 402, and 404 may also represent instantiations 

By way of example, FIG. 6A shows LSC facilities 353(a) of different task-implementing blocks of code, 

and 353(b), which facilitates communication via line 370. In one embodiment, there is associated with each task a 

Note that since the SFB's of FIG. 6 A co-reside in the same mailbox whose address is well-known to all the SFB's that 

CPU/chassis, no trunk resources are necessary. Interface line need to communicate with instantiations of that task. As the 

356 delineates the configuration-independent portion of the 30 term is used herein, a mailbox represents a section of 

CILB, i.e., that portion above interface line 356 which memory to which messages may be posted for forwarding or 

interacts with the SFB's in a consistent manner irrespective retrieval. In this embodiment, all the SFB's that instantiate 

of network configuration, and the implementation details from a given task are associated with the one mailbox with 

within the CILB below interface line 356. Those implemen- 35 which the task is associated. In another embodiment, 

tation details may be modified to ensure proper data routing however, each SFB may have associated with it its own 

between the SFB's in a specific network configuration. mailbox. Note that a mailbox is necessary for receiving 

In FIG. 6B, BSC SFB 350 and BTS SFB 352 are messages. If a SFB only sends messages, a mailbox is not 

distributed in different CPU's/chassis. Communication absolutely necessary. 

between these two SFB's still preferably utilizes the Abis 40 To communicate among the SFB's of FIG. 7, the sending 

protocol (dotted line 354). However, the primitives below SFB needs to know the identity of the mailbox associated 

CILB line 356 change to facilitate remote communication. with the task from which the receiving SFB instantiates in 

For ease of understanding, primitives may be thought of as order to post a message, a request, or data in general to the 

functions that facilitate communication vertically up and 45 receiving SFB. Note that the sending SFB does not need to 

down the stacks. A protocol is defined by the message know the name or the specific location in the network of the 

structure (syntax), semantics, and message flows, and are receiving SFB. This is the case even though the SFB is the 

represented as horizontal lines in FIG. 6A and FIG. 6B. A entity that is executed, and there may exist more than one 

protocol stack may be thought of as a layering of applica- SFB's associated with a mailbox. 

tions such that each application layer performs a well 50 By way of example, a BTS administration SFB (328) of 

defined function in the context of the overall communication FIG. 5 may post a message to a particular BTS manager SFB 

subsystem. It operates according to a defined protocol by 322 (also of FIG. 5) by sending the message to the mailbox 

exchanging messages, both user data and additional control associated with the BTS manager task. The destination BTS 

information, with a corresponding peer layer in a remote 55 manager SFB 322, which has been monitoring this mailbox, 

system. Each layer has a well defined interface between may then pick up the posted message from the mailbox, 

itself and the layer immediately above and below. Depending on the nature and content of the message, the 

Consequently, the implementation of a particular protocol destination BTS manager SFB 322 then may either forward 

layer is independent of all other layers. The communication the message to another mailbox or reply with another 

between a layer and the layer immediately above and below 60 message by posting it to the mailbox associated with the 

is accomplished via primitives. BTS administration task. The pseudocodes for sending as 

In the example of FIG. 6B, the primitives implementing well as retrieving and processing of messages are shown in 

the Abis stacks 361(a) and 361(6) at layer two utilizes FIG. 7. 

LAPD. As shown, LAPD blocks 364A and 364B are imple- 65 At layer 1, the CILB may also be implemented via an 

mented as layer two and El facilities are implemented as interface function paradigm. FIG. 8 illustrates how multiple 

layer one. In contrast, message passing is the preferred SFB's may utilize subroutines in a library of subroutines 450 
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to communicate in a configuration independent manner. In an El layer (shown by line 503), which facilitates commu - 

accordance with the interface function paradigm, SFB's 452 nication between El SFB's. If Tl had been used as the 

and 454 can make calls to library of subroutines 450 to link, physical layer, communication between the SFB's above 

either dynamically or at linking time, the subroutines therein interface line 501 would preferably remain substantially 

that those SFB's need to communicate among each other. 5 unchanged. Only the data routing details beneath interface 

Examples of function calls to the library of subroutine 450 line 501 need to change below interface line 501 when Tl 

include calls to subroutines for sending messages, receiving is used instead of El. As is apparent, there may exist within 

messages, timing management, network management one stack well-defined interfaces between a higher layer and 

interfaces, and the like. Note that each subroutine may be the next lower layer to improve modularity and to simplify 

utilized by multiple SFB's. For example, a subroutine that 30 implementation and changes (for example, between BTS 

reads or writes to files may be utilized by every SFB's that SFB 492 and LAPD SFB 502(b) or between LAPD SFB 

interacts with the disc drive. 502(6) and layer one SFB 504(6)). 

To facilitate configuration -independent communication, Note that the communication between primitives them* 

the manner in which these subroutines are called preferably is selves may be accomplished via either the aforementioned 

remain substantially unchanged regardless of network con- message passing paradigm or the interface function para- 

figuration. Further, the implementation details of how data is digm. By way of example, the communication in FIG. 9(a) 

routed are preferably hidden in the subroutines from both the between LAPD SFB 502(a) and layer one SFB 504(a) (as 

sending and the receiving SFB's. That way, the subroutines well as between LAPD SFB 502(6) and layer one SFB 

can be utilized by, for example, application developers 20 504(6)) utilizes the interface function paradigm for their 

without requiring any knowledge of its underlying data communication. On the other hand, the communication 

routing details and without having to take into account between BSC SFB 490 and LAPD SFB 502(a) (and likewise 

network configuration. When network configuration between BTS SFB 492 and LAPD SFB 502(6)) is imple- 

changes, neither the sending or the receiving SFB's, or the 25 mented using message passing. 

manner in which they communicate with the subroutines, By way of example, FIG. 9B shows the communication, 

need to be substantially changed. Only the data routing using the inventive configuration independent architecture 

details, which are hidden in the subroutines from both the technique, between a BSC SFB and an MSC SFB. 

sending and the receiving SFB's, need to be modified to FIG. 10 illustrates the message passing paradigm for 

ensure proper data routing when network configuration 30 communicating among different SFB's. In FIG. 10, the BSC 

changes. As is apparent, this inventive aspect advanta- SFB 300 of FIG. 5 is used as an example although it should 

geously simplifies upgrade, maintenance, and network be kept in mind that the message passing paradigm may be 

expansion since the major SFB's are left essentially sub- utilized to facilitate configuration-independent communica- 

stantially unchanged. 35 tion among any SFB that is capable of communicating by 

FIG. 9A shows a multiple-layer communication stack for posting messages. By way of example, communication 

communicating among SFB's. Above an interface line 500, among the BTS SFB, the MSC SFB, the radio-dependent 

the two SFB's (BSC SFB 490 and BTS SFB 492) commu- SFB's, and the remote communication SFB's may also be 

nicate using application layer protocol, shown representa- implemented by message passing. 

tively by dotted line 494. Protocols are defined by the 40 FIG. 10 shows BSC SFB 300, CILB 306 (which imple- 

message structure (syntax), semantics, and message flows ments the A interface), and CILB 304 (which implements the 

for communicating across the stacks in FIG. 9A. Note that Abis interface). Inside BSC SFB 300, there are further 

dotted line 494 does not represent the actual data commu- shown a BSC administration SFB, a BTS manager SFB, a 

nication path between BSC SFB 490 and BTS SFB 492. 45 channel manager SFB, and a handover manager SFB. BSC 

Instead, these SFB's call on primitives, which are functions administration SFB implements the operation, 

for communicating down the stacks. The primitives utilize administration, and management (OA&M) functions while 

resources in the layers below interface line 500 of the CILB BTS manager SFB handles BTS dependent functions within 

to facilitate communication between the SFB's. the BSC, such as configuring the individual BTS's. The 

Data routing beneath interface line 500 of the CILB is 50 channel manager SFB handles, among other functions, the 

implemented by a multiple layer stack comprising a LAPD allocation of radio channels within the BTS's. Handover 

layer (shown representatively by dotted line 496), which manager SFB maintains performance statistics of individual 

facilitates communication between LAPD SFB's 502(a) and radio frequencies, time slots in a BTS for the purpose of 

502(6). The primitives above interface line 500 comprise the 55 handover preparation and execution. Each of the aforemen- 

CILB and preferably remain substantially unchanged irre- tioned SFB's is associated with a mailbox having a well- 

spective of how the primitives below this interface line 500 known address to which messages from other SFB's may be 

handle data routing in a specific network configuration. posted. 

In the specific example of FIG. 9A, LAPD SFB's 502(a) There is shown inside CILB 304 an Abis interface SPB 

and 502(6) further employ primitives to communicate down 60 600 for implementing the details necessary to route data 

the stack to layer one SFB's 504(a) and 504(6), which using the Abis protocol. Abis SFB 600 is associated with a 

actually transmit and receive the data on a transmission mailbox MBX4 whose address is also well-known, 

medium. Interface line 501 represents the delineation Likewise, CILB block 306 includes an A-interface SFB 602 

between the LAPD layer and the physical layer, which 65 for implementing the details necessary to route data using 

happens to be El in the example of FIG. 9 A. In the example the A interface. A-interface SFB 602 is associated with a 

of FIG. 9A, data routing beneath interface line 501 includes mailbox MBX1 having a well-known address to which 
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messages from other SFB's, e.g., SFB's inside BSC SFB preferably no entry in the routing table. If an entry for the 

300 may be posted. As is mentioned earlier, the mailbox receiving mailbox is absent in the routing table, it is then 

associated with a SFB may either be specifically associated assumed that the message routing should be local and no 

with the SFB itself or be associated with the task underlying intermediate handler function needs to be invoked. In 

the SFB, and all SFB's which instantiate from that task arc 5 another embodiment, all mailboxes are listed in routing table 

associated with the same mailbox. 630 for consistency. For example, those remoted from the 

In one embodiment, there is provided a routing table sending SFB may have corresponding intermediate handler 

associated with each CPU. The routing table furnishes mailboxes while those local to the sending SFB have, as 

information to facilitate data routing in a particular network corresponding mailboxes, their own mailbox ID's. Other 

configuration. The data routing information may then be methods of routing may be utilizxd in place of routing table 

used by the configuration-specific CILB codes to correctly 630. For example, routing based on spanning tree or using 

forward messages received from the sending software func- the Dykstra algorithm has been contemplated as suitable 

tion block. In one embodiment, if a message needs to be alternatives. 

posted to mailbox associated with a SFB that is remoted 15 FIG. 12 illustrates the communication between the BSC 

from the sending SFB or to multiple SFB's, the manner in administration SFB 700 and A-interface SFB 602 when 

which the sending SFB sends its message preferably remains these two SFB's are remoted from one another. As shown in 

substantially unchanged across different network configura- FIG - 12 » A-interface SFB 602 is implemented on an El card 

tions. In particular, it is preferable that the manner in which 702 separate from CCPU card 704. For further information 

the sending SFB addresses its messages remains substan- 20 regarding CCPU cards, reference may be made to the 

tiallv unchanged aforementioned co-pending patent application Ser. Nos. 

J . " . 4 . , - 08/435,709, 08/434,554, 08/434,598, and 08/434,597. The 

However, when that message is sent from the sending ' ' ' ' , _r, ' „ . ' . 

cirn a • .u run *l rair • « . n couphng between CCPU card 704 and El card 702, which 

SFB, codes in the CILB cause the CPU to first consult a ^ & ^ fir$t _ out ^ m 

routing table to determine whether it is necessary to route the 25 M qq{ ^ mFQ ^ m ^ pfef _ 

message to a mailbox associated with an intermediate han- erM implemented on El card 702 itself 

dler routine. The intermediate handler routine, which is , n the embodimenl of mG 12> there m shown interme . 

coded for a particular network configuration and whose data diate handkr Mocks 708 and no fof facilitating 

routing details are hidden from both the sending and receiv- remote mmm}micAt]on across FIF0 706. Intermediate han- 

mg SFB's, is then responsible for forwarding that message 3U dler mnct i on block 708 handles the communication with 

to the appropriate destination mailbox in the network. CCPU card 70 4 while intermediate handler function block 

To illustrate, FIG. 11 shows an example of a routing table 710 facilitates communication with El card 702. When 

630 associated with a CPU in which there are two columns, A-interface SFB 602 wishes to post a message to BSC 

650 and 652. Column 650 shows the identity of the mailbox 35 administration software function block 700, it sends a mes- 

to which a sending SFB desires to post a message. Column sage to the mailbox associated with the BSC administration 

652 shows a corresponding identity of a mailbox associated software function block 700, i.e., to mailbox MBX2. Before 

with an intermediate handler routine to which the message the message is routed to mailbox MBX2, the CPU on El 

must first be posted. card 702 first consults a routing table 714 to determine 

By way of example, if a sending SFB wishes to post a 40 whether the message should first be posted to a mailbox 

message to mailbox MBX1, codes in the CILB causes the associated with an intermediate handler function (as would 

CPU handling the posting of that message to first consult be the case if the destination SFB is remoted or if there are 

with routing table 630 to determine whether this message multiple instantiations of the same task), 

should first be routed to a mailbox associated with an 45 Routing table 714 is typically stored in the persistent 

intermediate handler routine. According to table 630, mes- storage on the chassis, such as a hard disk, flash memory, 

sages to mailbox MBX1 should first be routed to mailbox and the like (shown by element 712 in FIG. 12). A sample 

MBY1. The intermediate handler routine associated with routing table is shown as table 714 in FIG. 12. Routing table 

mailbox MBY1 will then route the message according to its 714 indicates that messages posted to a mailbox MBX2 

knowledge of the specific network configuration. The use of 50 should first be posted to mailbox MBX 21 which, as shown 

intermediate handler routines is explored in greater details in in FIG. 12, is associated with intermediate handler function 

FIGS. 12 and 13. block 708. Therefore, the message will first be routed to 

Note that the use of routing tables and intermediate mailbox MBX21. The message sent to mailbox MBX21 

handler routines advantageously hides the configuration- 55 preferably includes information regarding the final destina- 

specific data routing details from both the sending and the tion for the message, i.e., the identity of mailbox MBX2. 

receiving SFB's. From the perspective of the sending SFB, Intermediate handler function block 708, which monitors 

all it needs to do is post a message to destination mailbox, the address associated with mailbox MBX21, then retrieves 

e.g., mailbox MBX1. Knowledge regarding whether the the message from mailbox MBX21 and forwards it to FIFO 

SFB associated with that mailbox MBX1 is remote or local 60 706 to be subsequently retrieved by intermediate handler 

with respect to the sending SFB and how that message function 710. Using the destination mailbox MBX2 in the 

should be routed in a given network configuration is hidden message retrieved, intermediate handler function 710 then 

by the use of routing table 630 and intermediate handler consults a routing table 718 to determine how to best route 

functions associated with mailbox MBY1. 65 the message it has just retrieved from FIFO block 706. 

In one embodiment, if both the sending SFB and the Routing table 718 is preferably kept in the persistent storage 

receiving SFB co-reside on the same CPU/chassis, there is facility on CCPU card 704 (shown as element 717). 
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Since mailbox MBX2 resides on CCPU card 704, no entry get forwarded to the correct instantiation irrespective of 

is required in routing table 718. Consequently, a consultation network configuration. In the context of the above example, 

with routing table 718 by intermediate handler block 710 it is important that messages intended for BTS 5 is for- 

will reveal no corresponding mailbox to which the message warded to BTS manager SFB 804 (which is implemented on 

retrieved from FIFO block 706 should be forwarded. Inter- 5 CCPU2 ) irrespective of where in the network this BTS 

mediate handler function block 710 forwards the message it manager SFB is implemented. 

retrieves from FIFO block 706 directly to mailbox MBX2 in ~ c . . 4 . . A 

*u r*nn/ u • i i j. . u Consider, for example, the communication between BSC 

the same CPU/chassis using local data routing to be , . . # " C17D Q ^ n . e _ OAjC ... 

retrieved by BSC administration SFB 700. administration SFB 800 and BTS manager SFB 806, which 

In the reverse direction, BSC administration SFB 700 10 contr °k BTS 8. Since the BTS manager SFB 806 is remote 

M . n _ . »ii UDV1 . . , ... relative to card CCPU1, which implements BSC admin is- 

may send a message to mailbox MBX1 associated with , , , . 

A-interface SFB 602 by first consulting routing table 718, * aU ° D bl ° ck "°' ™ intermediate handler function is uti- 

which directs the message to be routed to mailbox MBX20. * ized , l ° ha ° dle the configuration-specific data routing 

That message is then picked up by intermediate handler 1S ^ T ° llluStrate ' ^ ? P Tf Z , ™ ™ 

function 710 and forwarded to FIFO 706 to be retrieved by mana * er intermediate handler function block 810. BTS 

intermediate handler function 708. Using the destination manager intermediate handler ^function block 810 has asso- 

mailbox MBX1 in the message retrieved, intermediate han- cialed Wlth " a ^ ,box MBX22 > whose address * known m 

dler function 708 then consults routing table 714, which a r0Uting table 82 °* 

reveals that messages posted to mailbox MBX1 is local from 20 When BSC administration SFB 800 wishes to send a 

the perspective of intermediate handler function 708, caus- message to BTS manager SFB 806, it merely posts a 

ing the message to be forwarded to mailbox MBX1 locally messa & e 10 a maUbox associated with the task that instan- 

by message passing. x ™ its ®TS manager SFB 806, i.e., mailbox MBX6. Note that 

A-interface SFB 602, which monitors the address of 25 BSC administration SFB 800 does not need to know the data 

mailbox MBX1, then picks up the message. Note that as far roulin S details of an ? s P ecific nelwork configuration to post 

as A-interface SFB 602 and BSC administration SFB 700 messa S es t0 the well-known address of mailbox MBX6. 

are concerned, the format of the message sent and the ^ cpu associated with card CCPU1 then consults 

address of the destination mailbox need not be changed to routin g table 820 which reveals that messages posted to 

accommodate changes in network configuration. The inter- 30 mailbox MBX6 should be routed instead to mailbox 

nal details regarding data routing in a configuration specific MBX22, which is associated with BTS manager intermedi- 

manner are handled by the intermediate handler blocks 708 ate handler function block 810. Consequently, the message 

and 710, using their associated routing tables 714 and 718, intended for mailbox MBX6 is forwarded to mailbox 

as well as by FIFO 706 . 35 MBX22. 

In FIG. 12, although the BSC administration SFB and BTS manager intermediate handler function block 810, 

A-interface SFB are used to illustrate the inventive which monitors the address associated with mailbox 

configuration-independent architecture, it should be noted MBX22, then picks up the message and consults another 

that any SFB's that can communicate by message passing routing table 830, which reveals that the BTS manager SFB 

may be so implemented. 40 tnat handles BTS 8 resides on CCPU3. BTS manager 

FIG. 13 illustrates the communication between a single intermediate handler function 810 then forwards the mes- 

BSC administration SFB 800 and three BTS manager SFB's sa S e 10 card CCPU3, or more particularly to CCPU inter- 

804, 806, and 808, which are implemented on three discrete mediate handler function 832 thereon. 

CCPU cards. Multiple instantiations of the BTS manager 45 The CPU on CCPU3 then consults a routing table 840 

task may exist in different CPU's to handle different subsets which reveals that mailbox MBX6 is implemented on the 

of BTS's to increase the total number of BTS's that a single sa me CCPU as intermediate handler function 832. The 

BSC can manage. By way of example, BTS manager SFB communication between CCPU intermediate handler func- 

804 may handle BTS's 1 through 6, BTS manager SFB 806 tion 832 to mailbox MBX6 is therefore local, which may be 

may handle BTS's 7 through 12, and BTS manager SFB 808 50 Dv message passing in one embodiment. BTS manager SFB 

may handle BTS's 13 through 18. Note that each instantia- 806 » which monitors the address associated with mailbox 

tion of the BTS manager task is typically capable of han- MBX6 then picks up the message. 

dling a finite number of BTS's. As system capacity is In the other direction, when a BTS manager SFB 804 
increased, BTS's are added and additional BTS manager 55 wishes to send a message to BSC administration SFB 800, 
SFB's must be added as well to facilitate scaling. Although it sends that message to mailbox MBX2, which is associated 
three BTS manager SFB's are shown in FIG. 13, a greater with the BSC administration task and which has a well- 
or a fewer number may of course be provided depending on known address. The CPU which runs BTS manager SFB 804 
network domain and capacity requirements. first consults a routing table 850, which reveals that mes- 
Since BTS manager SFB's 804, 806, and 808, being 60 sages intended for mailbox MBX2 should first be routed to 
configuration-independent, have no knowledge of each a mailbox MBX23, which is associated with CCPU inter- 
other, they all associate themselves with the same mailbox mediate handler function 852. In one embodiment, routing 
MBX6. In FIG. 13, BSC administration SFB 800 commu- tables 840 and 850 are substantially similar, 
nicates with all BTS manager SFB's, which may be distrib- 65 CCPU intermediate handler function 852, which monitors 
uted across multiple CPU's/chassis. It is important, the address of mailbox MBX23, then picks up the message 
however, that messages from BSC administration SFB 800 and forwards it to BTS manager intermediate handler func- 
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tion 810. The CPU on CCPU1 card then consults its asso- 
ciated routing table 830, which reveals that mailbox MBX2 
(it knows that the message is intended for mailbox MBX2 
from the content of the message) is local to CCPU1 card. 
Therefore, the message is forwarded to mailbox MBX2 on 5 
CCPU card in a local manner, which may be message 
passing in one embodiment for retrieval by BSC adminis- 
tration SFB 800. 

Note that the architecture model of FIG. 10 is still 10 
enforced regardless whether the BTS manager SFB's are 
remoted across different CCPU cards as are shown in FIG. 
13, are all implemented on a remote CCPU card relative to 
BSC administration SFB 800, or all co-reside with the BSC 
administration SFB 800 on the same CPU/chassis. All BSC 
administration SFB 800 has to do to send messages to a 
particular BTS manager SFB is to post those messages to the 
one well-known BTS manager mailbox, i.e., MBX6. The 
internal details regarding how the data should be routed 20 
among the CCPU cards in a specific network configuration 
are handled by the intermediate handler functions. 

When the system configuration changes, it is the inter- 
mediate handler function codes that are changed. There is no ^ 
need for changes in the codes making up either the BSC 
administration SFB 800, BTS administration SFB's 804, 
806, and 808, or the manner in which these SFB's address 
their messages. Further, the communication between BSC 
administration SFB 800 and the BTS manager SFB's is 30 
consistent from the perspective of the SFB's regardless of 
network configuration. 

Although the foregoing invention has been described in 
some detail for purposes of clarity of understanding, it will ^ 
be apparent that certain changes and modifications may be 
practiced within the scope of the appended claims. By way 
of example, although the invention is discussed herein with 
reference primarily to a GSM system, it should be noted that 
the present invention is not so limiting. It is specifically 
contemplated that the inventive configuration independent 
architecture disclosed herein may be implemented in sys- 
tems using other specific protocols. Consequently, the scope 
of the invention is not limited to the specific examples given 
herein but is set forth in the appended claims. 
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GLOSSARY OF TERMS AND ABBREVIATIONS 
Abis: Protocol stack between a BTS and a BSC 
API: Application Programming Interface 50 
BCF: Base Station Control Function 
BSC: Base station Controller 
BSS: Base Station Subsystem 
BTS: Base Transceiver Station 

CC: Call Control Management 55 

CCPU: Cellular CPU 

cPBX: cellular Private Branch Exchange 

CILB: Configuration Independent Linkage Block 

DSP: Digital Signal Processing 

GMSC: Gateway for MSC 60 
GSM: Global Systems for Mobile Communication 
HLR: Home Location Registry 
ISDN: Integrated Services Digital Network 
LAPD-M: Link Access Protocol on the Dm (control) chan- 
nel 65 
LSC: Local Software Functional Block Communication 
MM: Mobility Management 



MS: Mobile Stations 

MSC Mobile -Services Switching Center 

PSTN: Public Switched Telephone Network 

PBX: Private branch exchange 

RF: module Radio Frequency module 

RL: Radio Link 

RR: Radio Resource Management 

SCCP: Signalling Connection Control Part 

SFB: Software Functional Block 

SMS: Short Message Services 

SS: Supplemental Services 

TDM data: Time Division Multiplexed Data 

TRAU: Transcoder-Rate Adapter Unit 

TRX: Transceiver 

VLR: Visitor Location Registry 

VME: An industry standard bus for interconnecting com- 
ponents 

wPBX: wired PBX 

APPENDIX B 

The present disclosure is written for ease of understanding 
by those of skill in the art. For others, the following 
documents, incorporated herein by reference for all 
purposes, may be reviewed for additional information. 

Mouly, Michel & Pautet, Marie-Bernadette, "The GSM 
System for Mobile Communications" Mouly, Michel & 
Pautet, Marie-Bernadette, 1992. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
{Phase 2); Mobile radio interface signaling layer 3 General 
aspects (GSM 04.07)", 1994, Valbonne-France. 

European Telecommunications Standards Institute, 
"European digital telecommunications system (Phase 2); 
Mobile radio interface layer 3 specification (GSM 04.08)", 
1994, Valbonne-France. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
(Phase 2); Mobile-services Switching Centre-Base Station 
System (MSC-BBS) interface Layer 3 specification (GSM 
08.08)", 1994, Valbonne-France. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
(Phase 2); Signaling transport mechanism specification for 
the Base Station System-Mobile-services Switching Centre 
(BBS-MSC) interface (GSM 08.06)", 1994, Valbonne- 
France. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
(Phase 2); Base Station Controller-Base Transceiver Station 
(BSC-BTS) interface Layer 3 specification (GSM 08.58)", 
1994, Valbonne-France. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
(Phase 2); Mobile Application Part (MAP) specification 
(GSM 09.02)", 1994, Valbonne-France. 

European Telecommunications Standards Institute, 
"European digital cellular telecommunications system 
(Phase 2): Signaling requirements on internetworking 
between the Integrated Services Digital Network (ISDN) or 
Public Switched Telephone Network (PSTN) and the Public 
Land Mobile Network (PLMN) (GSM 09.03)", 1994, 
Valbonne-France. 
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#ifndef _SS7_IF_H 
#define _SS7_IF_H 
/• 

* Copyright (c) 1994, 1995 

* interWAVE Communications Inc, Redwood City, CA USA. All 

rights reserved. 
* 

@(#)$Header: /cvs/iw/include/ss7_if.h,v 1.5 1995/09/14 21:01:03 
phc Exp $ 

* DESCRIPTION: Structure definitions that define the messages that go 

* between NMI & trillium stack. 
V 

externint ss7_msc_mbx; 

#define SS7_SENDMSG(msg) (ss7_msc_mbx == MBX_SS7JF) ? \ 
ElMsgSend(ss7_slot / MBX_SS7JF, \ 

MEDIUM.PRIORITY, (tIwMsgHdr*)msg) 

I wMsgSend (ss7_msc_mbx / 

MEDIUM.PRIORITY, \ 

(t!wMsgHdr*)msg) 



#define SS7_NULL_SPID (Oxffff) 
#define SS7_NULL_SUID (Oxffff) 
#define SS7_NULL_SSN (Oxffff) 
#define SS7_NULL_PC (Oxffffffff) 

#define SS7_SP_CFC_REQ (1) 
#define SS7_SN_CFG_REQ (2) 
#define SS7_SD_CFG_REQ (3) 
#define SS7__QLCFG_REQ (4) 
#define SS7_PWR_UP (6) 

/* Following messages go from SS7 stack to the IWP */ 

#define SS7_SP_UDAT_IND (7) 

#define SS7_SP_UI_STA_IND (8) 

#define SS7_SP_CORD_IND (9) 

#define SS7_SP_CORD_CFM (10) 

#define SS7_SP_STE_IND (11) 

#define SS7_SP_PC_STE_IND (12) 
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#define SS7_SP_CON_IND (13) 

#define SS7_SP_CON_CFM (14) 

#define SS7_SP_DAT_IND (15) 

#define SS7_SP_EDAT_1ND (16) 
#define SS7_SP_DAT_ACK_IND (17) 

#define SS7_SP_RST_IND (18) 

#define SS7_SP_RST_CFM (19) 

#define SS7_SP_DISJND (20) 

#define SS7.SPJNFJND (21) 

/* Following message go from IWP to the SS7 stack */ 

#define SS7_SP_BND_REQ (22) 

#define SS7_SP_UBND_REQ (23) 

#define SS7_SP_UDAT_REQ (24) 

#define SS7_SP_CORD_REQ (25) 

#define SS7_SP_CORD_RSP (26) 

#define SS7_SP_STE_REQ (27) 

#define SS7_SP_CON_REQ (28) 

#define SS7_SP_CONLRSP (29) 

#define SS7_SP_DAT_REQ (30) 

#define SS7__SP_DAT_ACK_REQ (31) 

#define SS7_SP_EDAT_REQ (32) 

#define SS7_SP_RST_REQ (33) 

#define SS7_SP_RST_RSP (34) 

#define SS7_SP_DIS_REQ (35) 

#define SS7_SP_INF_REQ (36) 

#define SS7_SP_STA_REQ (37) 

#define SS7_SP_STA_IND (38) 

#define SS7_SP_STA_CFM (39) 

#define SS7_SP_STS_REQ (40) 

#define SS7_SP_STS_CFM (41) 

#define SS7_SN_STA_REQ (41) 

#define SS7_SN_STA_1ND (42) 

#define SS7_SN_STA_CFM (43) 

#define SS7_SN_STS_REQ (44) 

#define SS7_SN_STS_CFM (45) 

#define SS7_SD_STA_REQ (45) 

#define SS7_SD_STAJND (46) 

#define SS7__SD_STA_CFM (47) 

#define SS7_SD_STS_REQ (48) 

#define SS7_SD_STS_CFM (49) 

#define SS7_QI_STA_REQ (50) 

tfdefine SS7_QI_STA_IND (51) 
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#define SS7_QI_STA_CFM (52) 
#define SS7_QI_STS_REQ (53) 
#define SS7_QI_STS_CFM (54) 

#define CPJTRIL_CONID(ss7_.con, triLcon)\ 

{(ss7_con)->suId = (tril_con)->suId;\ 
(ss7_con)->spId = (tril_con)->spId;\ 
(ss7_con)->suInstId = (tril_con)->suInstId;\ 
(ss7_con)->spInstId = (tril_con)->spInstId;( 

#define CP_SS7_CONID(triLcon / ss7_con)\ 

{(triLcon)->suId = (ss7_con)->suId;\ 
(tril_con)->spId = (ss7_con)->spId;\ 
(tril_con)->suInstId = (ss7_con)->suInstId;\ 
(triLcon)->spInstId = (ss7_con)->spInstId;| 

#define CP_SS7_ADDR(triLadr, ss7_addr)\ 

|(tril_adr)->ssn = (ss7_addr)->ssn;\ 
(rril_adr)->pc = (ss7_addr)->pc;\ 
(tril_adr)->pres = (ss7_addr)->valid;\ 
(trii_adr)->sw = SW_CCnT;\ 
(tril_adr)->nilnd = INATJND;\ 
(tril_adr)->rtglnd = RTE_SSN;\ 
(tril_adr)->ssnlnd = (ss7_addr)-> valid; \ 
(tril_adr)->pclnd = (ss7_addr)->valid;\ 
(triLadr)->gt.format = GTFRMT_0;| 

#define CP_TRIL_ADDR(ss7_adr, triLaddr)\ 

{(ss7_adr)->valid = (tril_addr)->pres & (tril_addr)->ssnlnd & 

(tril_addr)->pclnd;\ 
(ss7_adr)->ssn = (tril_addr)->ssn;\ 
(ss7_adr)->pc = (tril_addr)->pc;| 

#ifdef SP 
typedef struct ( 

tlwMsgHdr Hdr; 

SpMngmt mgmt; 
| tss7_sp_cfg; 

#define S1ZE_SS7_SP_CFG (sizeof(tss7_sp_cfg)) 

typedef struct { 

tlwMsgHdr Hdr; 

SpMngmt sta; 
) tss7_sp_sta_req; 

#define SIZE_SS7_SP_STA_REQ (sizeof(tss7_sp_sta_req)) 
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typedef struct { 

tlwMsgHdr Hdr; 

SpMngmt sta; 
| tss7_sp_sta_ind; 
#define SIZE_SS7_SP_STAJND 

typedef struct ( 

tlwMsgHdr Hdr; 

SpMngmt sta; 
} tss7_sp_sta_cfm; 
#define SIZE_SS7_SP_STA_CFM 

typedef struct ( 

tlwMsgHdr Hdr; 

SpMngmt sts; 
) tss7_sp_sts_req; 
#define SIZE_SS7_SP_STS_REQ 

typedef struct ( 

tlwMsgHdr Hdr; 

SpMngmt sts; 
} tss7_sp_sts_cfm; 
#define SIZE_SS7_SP_STS__CFM 
#endif 



(sizeof(tss7_sp_sta_ind)) 



(sizeof(tss7_sp_sta_cfm)) 



(sizeof(tss7_sp_sts_req)) 



(sizeof(tss7_sp_sts_cfm)) 



#ifdef SN 
typedef struct f 

tlwMsgHdr Hdr; 

SnMngmt mgmt; 
} tss7_sn_cfg; 

#define SIZE_SS7_SN_CFG (sizeof(tss7_sn_cfg)) 



typedef struct \ 

tlwMsgHdr Hdr; 

SnMngmt sta; 
) tss7_sn_sta_req; 
#define SIZE_SS7_SN_STA_REQ 



typedef struct { 

tlwMsgHdr Hdr; 

SnMngmt sta; 
I tss7_sn_sta_ind; 
#define SIZE_SS7_SN_STA_IND 

typedef struct | 

tlwMsgHdr Hdr; 
SnMngmt sta; 



(sizeof(tss7_sn_sta_req)) 



(si zeof (tss7_sn_sta_ind)) 
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) tss7_sn_sta_cfm; 

#define SIZE_SS7_SN_STA__CFM 

typedef struct { 

tlwMsgHdr Hdr; 

SnMngmt sts; 
) tss7_sn_sts_req; 
#define SIZE_SS7_SNLSTS_REQ 

typedef struct { 

tlwMsgHdr Hdr; 

SnMngmt sts; 
( tss7_sn_sts_cfm; 
#define SIZE_SS7_SN__STS_CFM 
#endif 



(sizeof(tss7_sn_sta_cfm)) 



(sizeof(tss7_sn_sts_req)) 



(sizeof(tss7_sn_sts_cfm)) 



#ifdef SD 
typedef struct ( 

tlwMsgHdr Hdr; 

SdMngmt mgmt; 
| tss7_sd_cfg; 

#define SIZE_SS7_SD_CFG (sizeof(tss7_sd_cfg)) 



typedef struct ( 

tlwMsgHdr Hdr; 

SdMngmt sta; 
1 tss7_sd_sta_req; 
#define SIZE_SS7_SD_STA_REQ 



typedef struct ( 

tlwMsgHdr Hdr; 

SdMngmt sta; 
} tss7_sd_sta_ind; 
#define SIZE_SS7_SD_STAJND 

typedef struct ( 

tlwMsgHdr Hdr; 

SdMngmt sta; 
) tss7_sd_sta_cfm; 
#define SIZE_SS7_SD_STA_CFM 

typedef struct { 

tlwMsgHdr Hdr; 

SdMngmt sts; 
) tss7_sd_sts_req; 
#define S1ZE__SS7_SD_STS_REQ 



(sizeof(tss7_sd_sta_req)) 



(sizeof(tss7_sd_sta_ind)) 



(sizeof(tss7_sd_sta_cfm)) 



(sizeof(tss7_sd_sts_req)) 
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typedef struct ( 

tlwMsgHdr Hdr; 

SdMngmt sts; 
) tss7_sd_sts_cfm; 
#define SIZE.SS7_SD_STS.CFM 
#endif 



(sizeof(tss7_sd_sts_cfm)) 



#ifdefQI 
typedef struct { 

tlwMsgHdr Hdr; 

QiMngmt mgmt; 
) tss7_qi_cfg; 

#define SIZE_SS7_QI_CFG (sizeof(tss7_qLcfg)) 



typedef struct { 

tlwMsgHdr Hdr; 

QiMngmt sta; 
| tss7_qi_sta_req; 
#define SIZE_SS7_QI_STA_REQ 



typedef struct ( 

tlwMsgHdr Hdr; 

QiMngmt sta; 
| tss7_qi_sta_ind; 
#define SIZE_SS7_QI_STAJND 

typedef struct ( 

tlwMsgHdr Hdr; 

QiMngmt sta; 
| tss7_qi_sta_cfm; 
#define SIZE_SS7_QI_STA_CFM 

typedef struct { 

tlwMsgHdr Hdr; 

QiMngmt sts; 
) tss7_qi_sts_req; 
#define SIZE_SS7_QI_STS_REQ 

typedef struct { 

tlwMsgHdr Hdr; 

QiMngmt sts; 
| tss7_qi_sts_cfm; 
#define SIZE_SS7_QI_STSJZFM 
#endif 



(sizeof(tss7_qi_sta_req)) 



(sizeof(tss7_qLsta_ind)) 



(sizeof(tss7_qi_sta_cfm)) 



(sizeof(tss7_qLsts_req)) 



(sizeof(tss7_qi_sts_cfm)) 



typedef struct ( 

tlwMsgHdr Hdr; 
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ul6 suld; 
ul6 spld; 
ul6 ssn; 
u8 type; 
) tss7_sp_bnd_req; 

#define SIZE_SS7_SP_BND_REQ (sizeof(tss7_sp_bnd_req)) 

typedef struct { 

tlwMsgHdr Hdr; 

ul6 spld; 

u!6 reason; 
| tss7_sp_ubnd_req; 

#define SIZE_SS7_SP_UBND_REQ (sizeof(tss7_sp_ubnd_req)) 

typedef struct ( 

tlwMsgHdr Hdr; 

ul6 status; 
I tss7_pwr_up; 

#define SIZE_SS7_PWR_UP (sizeof(tss7_pwr_up)) 

typedef struct ( 

ul6 valid; 

ul6 ssn; 

u32 pc; 
) tss7_sp_addr; 

#define SIZE_SS7_SP_ADDR (sizeof(tss7_sp_addr)) 

typedef struct { 

tlwMsgHdr Hdr; 
ul6 Spld; 

tss7_sp_addr Cd; /* Called Address */ 
tss7_sp_addr Cg; /* Calling Address */ 
ul6 Len; /* Length of Data Field V 

u8 Data[0]; 
) tss7_sp_udat_req; 

#define SIZE_SS7_SP_UDAT_REQ(len) (sizeof(tss7_sp_udat_req) + len) 

typedef struct ( 

tlwMsgHdr Hdr; 
ul6 Suld; 

u32 OPc; /* Originating Point Code */ 

tss7_sp_addr Cd; /• Called Address V 
tss7_sp_addr Cg; /* Calling Addrress */ 
ul6 * Len; /* Length of Data Field V 
u8 Data[0]; 
1 tss7_sp_udat_ind; 

#define SIZE_SS7_SP_UDAT_IND(len) (sizeof(tss7_sp_udaUnd) + len) 
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typedef struct { 

ul6 suld; 

ul6 spld; 

u32 sulnstld; 

u32 splnstld; 
) tss7_sp_conid; 

#define SIZE_SS7_CONID (sizeof(tss7_conid)) 

typedef struct { 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

tss7_sp_addr Cd; /• Called Address 7 

tss7_sp_addr Cg; /* Calling Addrress */ 

ul6 Len; 

u8 Data[0]; 
) tss7_sp_con_req; 

#define SIZE_SS7_SP_CON_REQ(len) (sizeof(tss7_sp_con_req) + 
len) 

typedef struct ( 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

tss7_sp_addr Cd; 

tss7_sp_addr Cg; 

ul6 Len; 

u8 Data[0]; 
) tss7„sp_con_ind; 

#define SIZE_SS7_SP_CON_IND(Ien) (sizeof(tss7_sp_con_ind) + 
len) 

typedef struct ( 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

tss7_sp_addr RspAdr; 

ul6 Len; 

u8 Data[0]; 
} tss7_sp_con_rsp; 

#define SIZE_SS7_SP_CON_RSP(len) (sizeof(tss7_sp_con_rsp) + len) 

typedef struct | 

tlwMsgHdr Hdr; 
tss7_sp_conid Conld; 
tss7_sp_addr RspAdr; 



ul6 Len; 
u8 Data[0]; 
} tss7_sp_con_cfm; 
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#define SIZE_SS7_SP_CON_CFM(len) (sizeof(tss7 sp_con_cfm) + 
len) 

typedef struct ( 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

tss7_sp__addr RspAdr; 

u8 Reason; 

u8 Orig; 

ul6 Len; 

u8 Data[0]; 
I tss7_sp_dis_req; 

#define SIZE_SS7_SP_DIS_REQ(len) (sizeof(tss7_sp_dis_req) + ien) 

typedef struct | 

tlwMsgHdr Hdr; 
tss7_sp_conid Conld; 
tss7_sp_addr RspAdr; 
u8 Reason; 
u8 Orig; 
ul6 Len; 



1 tss7_sp_dis_ind; 
#define SIZE_SS7_SP_DIS_IND(len) (sizeof(tss7_sp_dis_ind) + len) 

typedef struct { 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

ul6 Len; 

u8 Data[0]; 
} tss7_sp_dat_req; 

#define SIZE_SS7_SP_DAT_REQ(len) (sizeof(tss7_sp_dat_req) + 
len) 

typedef struct ( 

tlwMsgHdr Hdr; 

tss7_sp_conid Conld; 

ul6 Len; 

u8 Data[0]; 
I tss7_sp_dat_ind; 

#define SIZE_SS7^SP_DAT_IND(Ien) (sizeof(tss7„sp_dat_ind) + len) 

extern u32 ss7_slot; /* Slot of the El card that holds the ss7 stack •/ 
extern ul6 bssap_spid; 
extern ul6 bssap_suid; 
extern ul6 bssap_ssn; 
extern u32 them_pc; 



u8 



Data[0]; 
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extern u32 us_pc; 

extern int ss7_sp_bnd_req(ul6 suld, ul6 spld, ul6 ssn, u8 type); 
extern int ss7_sp_ubnd_req(ul6 spld, u8 reason); 

extern int ss7_sp_udat_req(ul6 spld, tss7_sp_addr *cd, tss7_sp_addr »cg, 

ul6 len, u8 *data); 
extern int ss7_sp_con_req(tss7_sp_conid *conid, tss7_sp_addr *cd, 

tss7_sp_addr *cg, ul6 len, u8 *data); 
extern int ss7_sp_con_rsp(tss7_sp_conid *conid, tss7_sp_addr *rsp, ul6 
len, 

u8 Mata); 

extern int ss7_sp_dat_req(tss7_sp_conid *conid, ul6 len, u8 *data); 
extern int ss7_sp_dis_req(tss7_sp_conid *conid, tss7_sp_addr *rsp, u8 
reason, 

u8 originator, ul6 len, u8 *data); 
#endif /* _SS7JF_H V 



WAVEP005 -45- 



07/02/2004, EAST Version: 1.4.1 



41 

What is claimed is: 

1. A configuration-independent software architecture for 
implementing a cellular communication network, said cel- 
lular communication network facilitating communication 
among a plurality of cellular handsets, comprising: 

a first software functional block for implementing a first 
set of functions; 

a second software functional block for implementing a 
second set of functions; and 

a configuration-independent linkage block having an 
interface that appears consistent to both said first soft- 
ware functional block and said second software func- 
tional block irrespective of a relative position between 
said second software functional block, said first soft- 
ware functional block, and said configuration- 
independent linkage block in said cellular communica- 
tion network, said configuration-independent linkage 
block facilitating communication between said first 
software functional block and said second software 
functional block via said interface utilizing 
configuration-independent linkage block, wherein said 
first software functional block, said second software 
functional block, and said interface remain substan- 
tially unchanged when said first software functional 
block changes its location in the cellular communica- 
tion network relative to said second software functional 
block. 

2. The network of claim 1 wherein said first software 
functional block is a base transceiver station software func- 
tional block and said first set of functions is a set of base 
transceiver station functions, said second software func- 
tional block is a base station controller software functional 
block and said second set of functions is a set of base station 
controller functions. 

3. The network of claim 2 wherein said interface com- 
prises primitives for implementing an Abis interface and 
said configuration -independent linkage block comprises 
internal functions implementing LAPD functionalities for 
facilitating remote communication between said base trans- 
ceiver station software functional block and said base station 
controller software functional block. 

4. The network of claim 3 wherein said base transceiver 
station software functional block and said base station 
controller software functional block are executed in two 
different central processing units, said two different central 
processing units residing on a common chassis. 

5. The network of claim 3 wherein said base transceiver 
station software functional block and said base station 
controller software functional block are executed in two 
different central processing units, said two different central 
processing units residing on two different chassis. 

6. The network of claim 2 wherein said interface com- 
prises primitives for implementing an Abis interface and 
said configuration-independent linkage block comprises 
internal functions implementing local software functional 
block communication for facilitating local communication 
between said base transceiver station software functional 
block and said base station controller software functional 
block. 

7. The network of claim 6 wherein said base transceiver 
station software functional block and said base station 
controller software functional block are executed using a 
single central processing unit. 

8. A method for facilitating communication among a 
plurality of software functional blocks in a cellular commu- 
nication network, said cellular communication network hav- 
ing a plurality of central processing units, said method 
comprising: 
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providing a first software functional block for implement- 
ing a first set of functions, said first software functional 
block being executed on a first central processing unit 
in said cellular communication network; 

5 providing a second software functional block for imple- 
menting a second set of functions, said second software 
functional block being a first instantiation of a block of 
codes representing said second set of functions; 
providing a third software functional block for imple- 

10 menting said second set of functions, said third soft- 
ware functional block being a second instantiation of 
said block of codes representing said second set of 
functions; and 
facilitating configuration-independent communication 

15 between said first software functional block and both 
said second and third software functional blocks using 
at least one configuration-independent linkage block, 
said configuration-independent linkage block having 
internal functions that transparently implementing, 

20 from the perspectives of said first, second, and third 
software functional blocks, configuration-specific com- 
munication among said first, second, and third software 
functional blocks, said configuration-independent com- 
munication takes place via an interface that is substan- 

25 tially consistent irrespective whether said second and 
third software functional blocks execute on said first 
central processing unit or on different central process- 
ing units in said cellular communication network, 
wherein said first, second, and third software functional 

30 blocks remain substantially unchanged across network 
configurations. 

9. The method of claim 8 wherein said first, second, and 
third software functional blocks and said interface remain 
substantially unchanged irrespective whether said second 

35 and third software functional blocks are executed on a 
second central processing unit that is different from said first 
central processing unit or on two different central processing 
units that are different from said first central processing unit. 

10. The method of claim 9 wherein said first software 
40 functional block is a base station controller software func- 
tional block and said first set of functions is a set of base 
station controller functions, said second software functional 
block is a base transceiver station software functional block 
and said second set of functions is a set of base transceiver 

45 station functions, and said third software functional block is 
a base transceiver station software functional block imple- 
menting said set of base transceiver station functions. 

11. The method of claim 10 wherein said first software 
functional block is implemented on a first chassis and said 

50 second and third software functional blocks are imple- 
mented on a second chassis in said cellular communication 
network, said first and second chassis are remoted from one 
another and coupled together using trunk lines in said 
cellular communication network. 

55 12. The method of claim 11 wherein said second and third 
software functional blocks execute on two different central 
processing units in said second chassis. 

13, The method of claim 11 wherein said internal func- 
tions in said configuration-independent linkage block imple- 

60 ment LAPD facilities for facilitating remote communication 
between said first software functional block and one of said 
second and third software functional blocks. 

14. The method of claim 9 wherein said first software 
functional block is implemented on a first chassis, said 

65 second software functional block is implemented on a 
second chassis, and said third software functional block is 
implemented on a third chassis in said cellular communica- 
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tion network, wherein said first, second, and third chassis are 
remoted from one another and coupled together using trunk 
lines in said cellular communication network. 

15. The method of claim 14 wherein said internal func- 
tions in said configuration-independent linkage block imple- 5 
ment LAPD facilities for facilitating remote communication 
between said first software functional block and one of said 
second and third software functional blocks. 

16. The method of claim 9 wherein said first, second and 
third software functional blocks are implemented on the 10 
same chassis in said cellular communication network, said 
internal functions in said configuration-independent linkage 
block implement local software functional block communi- 
cation for facilitating local communication between said first 
software functional block and one of said second and third 15 
software functional blocks. 

17. The method of claim 9 wherein said first software 
functional block is a mobile station controller software 
functional block and said first set of functions is a set of 
mobile station controller functions, said second software 20 
functional block is a base station controller software func- 
tional block and said second set of functions is a set of base 
station controller functions, and said third software func- 
tional block is a base station controller software functional 
block implementing said set of base station controller func- 25 
tions. 

18. The method of claim 17 wherein said first, second, and 
third software functional blocks are implemented in a first 
chassis in said cellular communication network. 
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19. The method of claim 18 wherein said first software 
functional block is implemented on a first chassis while said 
second and third software functional blocks are imple- 
mented on chassis different from said first chassis. 

20. The method of claim 9 wherein said first software 
functional block is a base station controller software func- 
tional block and said first set of functions is a set of base 
station controller functions, said second software functional 
block is a TRX software functional block and said second set 
of functions is a set of TRX functions, and said third 
software functional block is a base station controller soft- 
ware functional block implementing said set of TRX func- 
tions. 

21. The method of claim 20 wherein said first, second, and 
third software functional blocks are implemented in a first 
chassis in said cellular communication network. 

22. The method of claim 21 wherein said first software 
functional block is implemented on a first chassis while said 
second and third software functional blocks are imple- 
mented on chassis different from said first chassis. 

23. The method of claim 22 wherein said second and third 
software functional blocks are executed on a different cen- 
tral processing units in said chassis different from said first 
chassis. 

* * * * * 
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